1. Field of the Invention
The present invention relates generally to databases and more specifically, to real time database systems or software that allows multithreading, multitasking and concurrency, of multiple users performing reading and writing over the database or shared public data section.
The present invention provides a method whereby a designated critical section monitors object status through employment of counters attached to the object's definition that will increment and decrement during reading and writing.
In essence all threads are readers whether a thread is a reader thread or a writer thread since writer threads must read first. Therefore, while the present invention provides for a reader thread and a writer thread, basically there are only reader threads that can be converted into reader/writer threads without creating a new thread once the reader/writer thread has acquired all the objects for updating whereupon those database sections are locked and updated as opposed to locking the whole database.
As aforementioned, the method assumes that all threads are reader threads and those threads that update the database will store those changes in a buffer or cache memory until the end of the transaction or API called then the changes will be committed to the source database.
This method not only prevents deadlocks since no reader can become a writer until all of the required object are obtained but should prove to be more resource efficient since only those parts of the database being updated are locked as opposed to locking sections of or the entire database.
In addition, the current methodology of listing and acquiring object lock in some numerical order to prevent deadlocks using traditional locking primitive doesn't work in a database environment where the object identifier is a customizable variable that is indeterminate until runtime. The method of the present invention requires no application processing to order object for locking. This means that the order of acquiring lock by object could be completely random.
In general, there are two kinds of threads, reader and writer, which will both be reading the database until the changes need to be committed. At that time the thread, which is ready to commit its changes, will try to convert the reader lock over all its objects that need to be updated into writer lock atomically, this means that only if the thread is able to convert all its reader lock into writer lock over every single object at once will it commit its changes. Otherwise, it won't lock any object to write or read and will wait for the next object to be released by other threads and try again.
The present invention also provides that all reader locks must be converted into writer locks atomically to preserve the integrity of the database, whereby all the changes will take place simultaneously so that other users will read the changes regardless if multiple objects were updated.
The present invention provides a global critical section that is used to protect the counters, hereinafter referred to as “m-read”, “m-writer”, “m-lock” and “m-threads waiting', which inclusively represent the stats of any object or resource.
In operation, the “m-read” value indicates how many threads are reading the object. Considering that the “m-writer” can only have a value of zero or one due to the requirement that only one thread can be writing or updating at any given time, “m-writer” indicates whether or not the object is being updated at any given time. Two fields comprise m-lock, “m_numberObjectsAssigned” and “m-eventHandle”. The field “m_numberObjectsAssigned” represents how many objects are sharing this lock “m_lock” in the protocol code it is used to find out when to recycle the lock handle “m-lock” and “m-eventHandle” is an event handler used to synchronize the threads. The event handler is used to initiate a thread wait state when needed and will be signaled by the reader group release and writer group release functions when they are finished with the object or resource.
2. Description of the Prior Art
There are other methods designed for database concurrent updating. Typical of these is U.S. Pat. No. 4,648,036 issued to Gallant on Mar. 3, 1987.
Another patent was issued to Mohan, et al. on Jan. 4, 1994 as U.S. Pat. No. 5,276,835. Yet another U.S. Pat. No. 5,452,450 was issued to Delory on Sep. 19, 1995 and still yet another was issued on Nov. 21, 1995 to Okada as U.S. Pat. No. 5,469,567.
Another patent was issued to Slingwine, et al. on Mar. 4, 1997 as U.S. Pat. No. 5,608,893. Yet another U.S. Pat. No. 6,363,387 was issued to Ponnekanti, et al. on Mar. 26, 2002. Another was issued to Landresse on Apr. 9, 2002 as U.S. Pat. No. 6,370,528 and still yet another was issued on Aug. 12, 2003 to Ponnekanti as U.S. Pat. No. 6,606,626.
Another patent was issued to Houston, et al. on Jan. 17, 2006 as U.S. Pat. No. 6,988,105. Yet another Canadian Patent No. CA2429154 was issued to Mullins on May 23, 2002. Another was issued to Ghukasyan on Dec. 12, 2002 as International Patent Application No. WO 02/099700 and still yet another was issued on May 5, 2004 to Nixon, et al. as U.K. Patent No. GB2394816.
A method of performing update transactions in a database system to preserve consistent logical data states at all times. Each changeable data entry in the database is associated with an individual code field. When no update transaction is in progress, every code field is set to a first value. An update transaction is begun by changing a system state parameter from a NON-UPDATE to an UPDATE state. During the UPDATE state, the code fields of data entries to be added are marked with a second value and then inserted into the database. Code fields of entries to be deleted are marked with a third value. When this is complete, the system state parameter is set to a POST-UPDATE state. All code fields are then returned to the first value at which time the system is returned to the NON-UPDATE state. During the UPDATE state, all queries are given access to entries with first and third code field value. Conversely during the POST-UPDATE state, queries are allowed access only to entries with first and second code field values.
A method of controlling entry of a block of data is used with a high-speed cache which is shared by a plurality of independently-operating computer systems in a multi-system data sharing complex. Each computer system has access both to the high-speed cache and to lower-speed, upper-level storage for obtaining and storing data. Management logic in the high-speed cache assures that the block of data entered into the cache will not be overwritten by an earlier version of the block of data obtained from the upper-level storage.
A database network management method ensures consistency of modifications to data in a network of databases comprising a relational database which constitutes a reference database and at least one further database accessible in real time. The data of the relational database is duplicated at least in part in the further databases accessible in real time. To enable an application process to modify data in all of the database network, the method is as follows: (1) A data modification request in the SQL language is sent from the application process to a pool of server processes of a relational database management system, (2) a server process is assigned to the request for the duration of its processing, (3) the modification request in the dynamic SQL language is sent from the server process pool to a relational database management system and the request is executed, (4) the further databases in accessible in real time to which the modification request relates are determined, (5) the request is transferred to the further databases in a form compatible with a management system of each further database concerned, and (6) the modification request is executed in each further database concerned.
The present invention is an improved database system for reducing the wait time for database processing programs. This data system provides for the input/output of blocks of data in excess of the capacity of the buffer pool assigned to the database processing program. When a database processing program tries to refer to the same block as one already under update processing by another database processing program or tries to update the same block as one already under update processing by another data processing program, the system allows a reference or update without placing the database processing system in the waiting state.
A substantially zero overhead mutual-exclusion apparatus and method (90, 120) is provided that allows concurrent reading and updating data while maintaining data coherency. That is, a data reading process executes the same sequence of instructions that would be executed if the data were never updated. Rather than depending exclusively on overhead-imposing locks, this mutual-exclusion mechanism tracks an execution history (138) of a thread (16, 112) to determine safe times for processing a current generation (108, 130, 131) of data updates while a next generation (110, 132, 133) of data updates is concurrently being saved. A thread is any locus of control, such as a processor. A summary of thread activity (106, 122) tracks which threads have passed through a quiescent state after the current generation of updates was started. When the last thread related to the current generation passes through a quiescent state, the summary of thread activity signals a callback processor (104, 124) that it is safe to end the current generation of updates. The callback processor then processes and erases all updates in the current generation. The next generation of updates then becomes the current generation of updates. The callback processor restarts the summary of thread activity and initiates a new next generation of updates. All data-updating threads pass through a quiescent state between the time they attempt to update data and the time the data are actually updated.
A Client/Server Database System with improved methods for enhancing concurrency using a “row update” bit and deferred locking is described. Data rows in the system are designed to include ROW_DELETE and ROW_UPDATE status bits. When a transaction updates a row, it sets the ROW_UPDATE bit. When a transaction inserts a row, neither the ROW_UPDATE nor the ROW_DELETE status bits are set. When a transaction deletes a row, it sets the ROW_DELETE bit but the contents of the data row are left intact. Methods are described for processing database transactions (e.g., in response to SQL queries) using these status bits or flags, together with deferred locking techniques, in a manner that reduces locking overhead and increase concurrency. The approach provides a particular performance advantage over systems that employ row-level locking.
A method is provided in a multi-processing system where multiple user programs can operate concurrently and simultaneously to access a series of database access methods which hold multiple buffer units. Thus, there can operate simultaneously a series of Write operations to the buffer units which copy the buffer information into specialized file structures followed by a parallel series of Input/Output completion operations which test the results of the copy operations followed by parallel and simultaneous writing to the file structures of the storage control information necessary to maintain their physical integrity.
A Client/Server Database System with an enhanced Lock Manager for improving concurrency is described. The system tracks information about database columns that are updated in the Lock Manager, in addition to the exclusive lock on the data row (in case of data row locking) or data page (in case of data page locking). In particular, a new field, lrcolumns, is added to the system's record lock data structure to track which columns have been modified. When an exclusive lock is requested on a row of the table being updated in the update statement, the Lock Manager sets the value of lrcolumns. In the context of an exclusive lock that was acquired to update one or more columns of a data row, if an exclusive lock was used only to insert or delete (but not update) the data row, the lrcolumns field would be set to 0. Similarly, the lrcolumns field is 0 for locks that are not exclusive locks (e.g., shared locks). With the Lock Manager enhancement of storing information about updated columns, scan (i.e., database scan operation) can skip a row (i.e., does not block for a lock on the row) if at least one of the sargs that the row does not qualify is on a column that was not updated by the updater. The approach avoids a lot of unnecessary blocking, thereby improving concurrency significantly.
A method and system for updating a database structure. The database structure includes a dynamically changing list of control documents. A control document specifies tasks to be performed on the database structure. An agent finds an approved control document on the list such as by looking into a view of control documents. Processing the approved control document includes causing an execution of at least one task on the approved control document. Execution of such a task includes updating of the database structure, and may be implemented by the agent that found the control document or by another agent called by the agent.
The present invention provides a system and method for dynamic object-driven database manipulation and mapping system (3A) which relates in general to correlating or translating one type of database to another type of database or to an object programming application. Correlating or translating involves relational to object translation, object to object translation, relational to relational, or a combination of the above. Thus, the present invention is directed to dynamic mapping of databases to selected objects. Also provided are systems and methods that optionally include caching components (3A, 51), security features (303), data migration facilities, and components for reading, writing, interpreting and manipulating XML and XMI data files (7, 51, 52, 8).
A dynamic database management system (FIG. 1) includes a data dictionary (101), a data importer (102) and a query front-end (103). The data importer automatically imports data from an input file into a database, while adding new tables for new attributes as necessary, and updating parameters and folders tables in the data dictionary accordingly, so that end-users may access the imported data by database queries through the query front-end.
Multiple clients are given concurrent access to a database component stored on a database by a server which has a shared cache. The cache has a memory store coupled to the database that holds a copy of the database component. The memory store has a store gate that controls access to the store. The clients when accessing the memory store do so with their own client thread each of which includes a server component that communicates with the store gate and the client with respect to the database component. The database server may include a notify thread that detects changes to the database component and notifies the memory store gate of the change. The store gate may then notify the client server components which then notify the clients which are accessing the changed database component. The database server may include a lock manager which causes the memory store gate to prevent writes to the memory store by all but one of the clients when the one client is writing to the memory store.
While these systems may be suitable for the purposes for which they were designed, they would not be as suitable for the purposes of the present invention, as hereinafter described.